home *** CD-ROM | disk | FTP | other *** search
/ New Star Software Collection / NSS_Collection.iso / tools / scp_setup.exe / {app} / scp_image_specs.txt < prev    next >
Encoding:
Text File  |  2017-12-05  |  23.9 KB  |  482 lines
  1. --------------------------------------------------------------------------------------
  2. Changes:
  3.  
  4. v1.3 - 11/20/14
  5.  
  6. * Changed structure info to add BYTE $000A as number of heads.  This has not been used
  7.   in any version of the SCP software, but will be starting with v1.6.
  8.  
  9. v1.4 - 11/21/14
  10.  
  11. * Redefined the HEADS definition and added it to BYTE $000A in IFF defines.
  12.  
  13. v1.5 - 01/12/16
  14.  
  15. * Extended track range.  This should not affect any programs using .scp image files
  16.   that followed the guidelines.
  17.   
  18. v1.6 - 12/05/17
  19.  
  20. * Added extension footer, courtesy of Natalia Portillo.
  21.  
  22. --------------------------------------------------------------------------------------
  23.  
  24. This information is copyright (C) 2012-2017 By Jim Drew.  Permissions is granted
  25. for inclusion with any source code when keeping this copyright notice.
  26.  
  27. ======================================================================================
  28.  
  29. The SuperCard Pro image file format will handle flux level images for any type of disk,
  30. be it 8", 5.25", 3.5", 3", GCR, FM, MFM, etc.
  31.  
  32. All longwords are in little endian format.  The words used for the flux length in the
  33. actual flux data are in big endian format... sorry, that's just how it worked out for
  34. the SuperCard Pro hardware.
  35.  
  36. All offsets are the start of the file (byte 0) unless otherwise stated.  The .scp image
  37. consists of a disk definition header, the track data header offset table, and the flux
  38. data for each track, which is preceeded by Track Data Header.  The format is described
  39. below:
  40.  
  41. BYTES 0x00-0x02 contains the ASCII of "SCP" as the first 3 bytes. If this is not found,
  42. then the file is not ours.
  43.  
  44. BYTE 0x03 is the version/revision as a byte.  This is encoded as (Version<<4|Revision),
  45. so that 0x39= version 3.9 of the format.  This is the version number of the SCP imaging
  46. software that created this image.  If bit 5 (FOOTER) of the FLAGS (byte 0x08) is set,
  47. this byte will be zero, and you are required to use the version and name entries in the
  48. extension footer.
  49.  
  50. BYTE 0x04 is the disk type and represents the type of disk for the image (see disk types
  51. in the defines).
  52.  
  53. BYTE 0x05 is the number of revolutions, which is how many revolutions for each track is
  54. contained in the image.
  55.  
  56. BYTES 0x06 and 0x07 are the start track and end track bytes.  Tracks are numbered 0-165,
  57. which is a maximum of 166 tracks (83 tracks with top/bottom).
  58.  
  59. BYTE 0x08 is the FLAGS byte.  This byte contains information about how the image was
  60. produced.  The bits are defined as follows:
  61.  
  62. Bit 0 - INDEX, cleared if the image did not use the index mark for queuing tracks
  63.                set is the image used the index mark to queue tracks
  64.                
  65. Bit 1 - TPI, cleared if the drive is a 48TPI drive
  66.              set if the drive is a 96TPI drive
  67.              
  68. Bit 2 - RPM, cleared if the drive is a 300 RPM drive
  69.              set if the drive is a 360 RPM drive
  70.  
  71. Bit 3 - TYPE, cleared for preservation quality image
  72.               set if flux has been normalized, reducing quality
  73.  
  74. Bit 4 - MODE, cleared if the image is read-only
  75.               set if the image is read/write capable
  76.  
  77. Bit 5 - FOOTER, cleared if the image does not contain an extension footer
  78.                 set if the image contains an extension footer
  79.   
  80. FLAGS bit 0 is used to determine when the reading of flux data started.  If this bit is
  81. set then the flux data was read immediately after the index pulse was detected.  If
  82. this bit is clear then the flux data was read starting at some random location on the
  83. track.
  84.  
  85. FLAGS bit 1 is used for determining the type of 5.25" drive was used.  Does not apply
  86. to any 3.5" drives.
  87.  
  88. FLAGS bit 2 is used to determine the approximate RPM of the drive.  When FLAGS bit 0 is
  89. clear, the index pulse is simulated using either a 166.6667ms (360 RPM) or 200ms (300 RPM)
  90. index pulse.
  91.  
  92. FLAGS bit 3 is used to determine if the image was made with the full resolution possible
  93. or if the image quality was reduced using a normalization routine that is designed to
  94. reduce the file size when compressed.
  95.  
  96. FLAGS bit 4 is used to determine if the image is read-only or read/write capable.  Most
  97. images will be read-only (write protected) for emulation usage.  The read/write capable
  98. images contain padded space to allow the track to change size within the image.  Only a
  99. single revolution is allowed when the TYPE bit is set (read/write capable).
  100.  
  101. FLAGS bit 5 is used to determine the presence of an extension footer after the end of
  102. the image.
  103.  
  104. BYTE 0x09 is the width of the bit cell time.  Normally this is always 0 which means
  105. 16 bits wide, but if the value is non-zero then it represents the number of bits for
  106. each bit cell entry.  For example, if this byte was set to 8, then each bit cell entry
  107. would be 8 bits wide, not the normal 16 bits.  This is for future expansion, and may never
  108. be actually used.
  109.  
  110. BYTE 0x0A is the head number(s) contained in the image.  This value is either 0, 1 or 2.
  111. If the value is 0 then both heads are contained in the image, which has always been the
  112. default for all SCP images (except C64).  A value of 1 means just side 0 (bottom) is
  113. contained in the image, and a value of 2 means just side 1 (top) is contained in the image.
  114.  
  115. BYTE 0x0B is reserved for future use.
  116.  
  117. BYTES 0x0C-0x0F are the 32 bit checksum of data starting from offset 0x10 through the
  118. end of the image file.  Checksum is standard addition, with a wrap beyond 32 bits
  119. rolling over.  A value of 0x00000000 is used when FLAGS bit 4 (MODE) is set, as no checksum
  120. is calculated for read/write capable images.
  121.  
  122. BYTES 0x10-0x2AF are a table of longwords with each entry being a offset to a Track Data
  123. Header (TDH) for each track that is stored in the image.  The table is always sequential.
  124. There is an entry for every track, with up to 168 tracks supported.  This means that disk
  125. images of up to 84 tracks with sides 0/1 are possible.  If no flux data for a track is
  126. present, then the entry will contain a longword of zeros (0x00000000).  The 1st TDH
  127. will probably start at offset 0x000002B0, but could technically start anywhere in the file
  128. because all entries are offset based, so track data does not have to be in any order.  This
  129. was done so you could append track data to the file and change the header to point to the
  130. appended data.  For simplicity it is recommended that you follow the normal image format
  131. shown below, with all tracks in sequential order.  The SuperCard Pro imaging software will
  132. always create a disk with all tracks and revolutions stored sequentially.
  133.  
  134.  
  135. TRACK DATA HEADER (TDH) INFO:
  136. ----------------------------
  137.  
  138. As stated, each entry is an offset to a Track Data Header.  That header contains
  139. information about the flux data for that track.  To help recover corrupt files,
  140. each entry has its own header starting with "TRK" as the first 3 bytes of the header and
  141. the track number as the 4th byte.
  142.  
  143. When imaging a single side only, the track data header entry will skip every other entry.
  144.  
  145. BYTES 0x00-0x02 ASCII 'TRK'
  146.  
  147. BYTE 0x03 contains the track number (0-165).  For single sided disks, tracks 0-42 (48TPI)
  148. or 0-82 (96TPI) are used.  For double-sided disks, the actual track number is this value
  149. divided by 2.  The remainder (0 or 1) is the head.  0 represents the bottom head and
  150. 1 represents the top head.  For example, 0x0B would be 11/2 = track 5, head 1 (top).
  151. Likewise, 0x50 would be 80/2 = track 40, head 0 (bottom).
  152.  
  153. Starting at BYTE 0x04 are three longwords for each revolution that is stored.  Typically,
  154. a maximum of five sets of three longwords are stored using the SuperCard Pro's imaging
  155. program, but this is user defined and can vary from image to image.  Using BYTE 0x05 of
  156. the main file header, you can determine the number of sets of three longwords (one for each
  157. revolution stored).  The three longwords for each entry are described below:
  158.  
  159. BYTES 0x04-0x07 contain the duration of the 1st revolution.  This is the time from index
  160. pulse to index pulse.  This will be either ~360RPMs or ~300 RPMs depending the drive.
  161. It is important to have this exact time as it is necessary when writing an image back to a
  162. real disk.  The index time is a value in nanoseconds/25ns for one revolution.  Multiply
  163. the value by 25 to get the exact time value in nanoseconds.
  164.  
  165. BYTES 0x08-0x0B contain the length of the track in bitcells (flux transitions).  If a
  166. 16 bit width is used (selected above), then this value *2 will be the total number of
  167. bytes of data that is used for that track (16 bit = 2 bytes per word).
  168.  
  169. BYTES 0x0C-0x0F contains the offset from the start of the Track Data Header (BYTE 0x00,
  170. which is the "T" in "TRK) to the flux data.  NOTE!!  THIS OFFSET IS *NOT* FROM THE
  171. START OF THE FILE!
  172.  
  173. If there were more revolutions, there would be three more longwords stored for each
  174. additional revolution.. example:
  175.  
  176. BYTES 0x10-0x1B would be the 2nd entry (duration2, length2, offset2).
  177. BYTES 0x1C-0x27 would be the 3rd entry (duration3, length3, offset3).
  178. BYTES 0x28-0x33 would be the 4th entry (duration4, length4, offset4).
  179. BYTES 0x34-0x3F would be the 5th entry (duration5, length5, offset5).
  180.  
  181. Note that image types with FLAGS bit 3 set (READ/WRITE capability) only uses a single
  182. revolution, but the space allocated for the flux data will be the maximum necessary to
  183. store the worst case requirement.  The actual flux data will be inside of this space
  184. and the current length will be accurate.  This allows the track to expand and contract
  185. inside of the allocated space without overlapping and corrupting the file.
  186.  
  187. Flux data for each revolution is always stored sequentially (like the disk is spinning
  188. multiple times) with SuperCard Pro's imager..  No break or skew occurs.  However, it is
  189. possible that flux data could be located anywhere in the file because everything is
  190. offset based.  For simplicity, please try to keep the revolutions sequential.  SuperCard
  191. Pro's imaging software always stores the revolutions sequentially.
  192.  
  193.  
  194. TIMESTAMP INFORMATION
  195. ----------------------------
  196.  
  197. After the last byte of flux data there will be a timestamp.  This timestamp is an ASCII
  198. string, ie: 1/05/2014 5:15:21 PM. Some implementations are known not to write it, so
  199. its presence is not guaranteed. Also its format depends on the region settings of the
  200. user that created the image. If the footer is present, implementations are required to
  201. use the timestamps on it.
  202.  
  203.  
  204. EXTENSION FOOTER INFO:
  205. ----------------------------
  206. The extension footer contains some metadata describing the contents and origins of the
  207. disk image. Its presence is indicated by setting bit 5 of the FLAGS (byte 0x08). Fields
  208. and their meanings will not be modified by future versions of the image format, only
  209. expanded prepending new fields to the existing ones. This way, software can safely
  210. ignore any new fields.
  211.  
  212. The extension footer, and any of the data its offsets point to, will always start
  213. after all of track data and the ASCII timestamp.  Since ASCII text characters have a
  214. value of 0x30 to 0x5F, it is safe to assume that if the first byte after the track data
  215. is not a valid ASCII value, that no timestamp is actually included (some apps using SCP
  216. format elected not to include a timestamp).  This first byte would be the start of the
  217. extension footer data.
  218.  
  219. All offsets are relative to the start of the image file, and all strings they point to
  220. are to be stored as null-terminated UTF-8 format, prefixed with a 16-bit little-endian
  221. length in bytes not counting itself or the null-termination.
  222. E.g.: "My app" => 0x06 0x00 0x4D 0x79 0x20 0x97 0x70 0x70 0x00
  223.  
  224. Because localization makes the ASCII timestamp be different depending on language and
  225. location user settings when creating an image, timestamps in the footer must be stored
  226. as a little-endian signed 64-bit count of seconds since 1st January 1970 00:00:00 in UTC.
  227.  
  228. BYTES 0x00-0x03 contains the offset from the start of the file where the null-terminated
  229. UTF-8 string containing the drive manufacturer is stored. If the value is 0, the string
  230. is not present in the file.
  231.  
  232. BYTES 0x04-0x07 contains the offset from the start of the file where the null-terminated
  233. UTF-8 string containing the drive model is stored. If the value is 0, the string is not
  234. present in the file.
  235.  
  236. BYTES 0x08-0x0B contains the offset from the start of the file where the null-terminated
  237. UTF-8 string containing the drive serial number is stored. If the value is 0, the string
  238. is not present in the file.
  239.  
  240. BYTES 0x0C-0x0F contains the offset from the start of the file where the null-terminated
  241. UTF-8 string containing the name of the user is stored. If the value is 0, the string is
  242. not present in the file.
  243.  
  244. BYTES 0x10-0x13 contains the offset from the start of the file where the null-terminated
  245. UTF-8 string containing the name of the application that created this image is stored.
  246. Applications supporting any version of this footer are required to store their name in
  247. this footer. If the value is 0, the string is not present in the file.
  248.  
  249. BYTES 0x14-0x17 contains the offset from the start of the file where the null-terminated
  250. UTF-8 string containing the user comments is stored. If the value is 0, the string is not   
  251. present in the file.
  252.  
  253. BYTES 0x18-0x1F contains the little-endian signed 64-bit count of seconds since
  254. 1st January 1970 00:00:00 in UTC corresponding to the date and time when the image was
  255. created.
  256.  
  257. BYTES 0x20-0x27 contains the little-endian signed 64-bit count of seconds since
  258. 1st January 1970 00:00:00 in UTC corresponding to the date and time when the image was
  259. last modified (e.g. adding this footer to old images, or adding new fields to this footer).
  260.  
  261. BYTE 0x28 is the version/subversion of the application that created this image as a byte.
  262. This is encoded as (Version<<4|Subversion), so that 0x15= version 1.5 of the application.
  263.  
  264. BYTE 0x29 is the version/revision of the SuperCardPro hardware as returned by the get
  265. info command. This is encoded as (Version<<4|Revision), so that 0x15= version 1.5 of the
  266. SuperCardPro hardware.
  267.  
  268. BYTE 0x2A is the version/revision of the SuperCardPro firmware as returned by the get
  269. info command. This is encoded as (Version<<4|Revision), so that 0x11= version 1.2 of the
  270. SuperCardPro firmware.
  271.  
  272. BYTE 0x2B is the revision of this format. This is encoded as (Version<<4|Revision), so
  273. currently it must be 0x16. Whenever the format is expanded, this revision will increase.
  274. Applications that encounter a revision higher than the last they know should treat the
  275. footer as they would with a known version.
  276.  
  277. BYTES 0x2C-0x2F contains the ASCII of "FPCS" as the last 4 bytes of the file.
  278.  
  279. ; ------------------------------------------------------------------
  280. ; SCP IMAGE FILE FORMAT
  281. ; ------------------------------------------------------------------
  282. ;
  283. ; 0000              'SCP' (ASCII CHARS)
  284. ; 0003              VERSION (nibbles major/minor)
  285. ; 0004              DISK TYPE
  286. ;                   UPPER 4 BITS ARE USED TO DEFINE A DISK CLASS (MANUFACTURER)
  287. ;                   LOWER 4 BITS ARE USED TO DEFINE A DISK SUB-CLASS (MACHINE)
  288. ;
  289. ;                   MANUFACTURER BIT DEFINITIONS:
  290. ;                   0000 = COMMODORE
  291. ;                   0001 = ATARI
  292. ;                   0010 = APPLE
  293. ;                   0011 = PC
  294. ;                   0100 = TANDY
  295. ;                   0101 = TEXAS INSTRUMENTS
  296. ;                   0110 = ROLAND
  297. ;
  298. ;                    SEE DISK TYPE BIT DEFINITIONS BELOW
  299. ;
  300. ; 0005              NUMBER OF REVOLUTIONS (1-5)
  301. ; 0006              START TRACK (0-165)
  302. ; 0007              END TRACK (0-165)
  303. ; 0008              FLAGS BITS (0=INDEX, 1=TPI, 2=RPM, 3=TYPE)
  304. ; 0009              BIT CELL ENCODING (0=16 BITS, >0=NUMBER OF BITS USED)
  305. ; 000A              NUMBER OF HEADS
  306. ; 000B              RESERVED
  307. ; 000C-F            32 BIT CHECKSUM OF DATA FROM 0x10-EOF
  308. ; 0010              OFFSET TO 1st TRACK DATA HEADER (4 bytes of 0 if track is skipped)
  309. ; 0014              OFFSET TO 2nd TRACK DATA HEADER (4 bytes of 0 if track is skipped)
  310. ; 0018              OFFSET TO 3rd TRACK DATA HEADER (4 bytes of 0 if track is skipped)
  311. ; ....
  312. ; 02AC              OFFSET TO 168th TRACK DATA HEADER (4 bytes of 0 if track is skipped)
  313. ; 02B0              TYPICAL START OF 1st TRACK DATA HEADER (always the case with SCP created images)
  314. ;
  315. ; ....              END OF TRACK DATA
  316. ; ????              TIMESTAMP (AS ASCII STRING - ie. 7/17/2013 12:45:49 PM)
  317. ;
  318. ; Start of extension footer
  319. ;
  320. ; ????              OFFSET TO DRIVE MANUFACTURER STRING (optional)
  321. ; ????              OFFSET TO DRIVE MODEL STRING (optional)
  322. ; ????              OFFSET TO DRIVE SERIAL NUMBER STRING (optional)
  323. ; ????              OFFSET TO CREATOR STRING (optional)
  324. ; ????              OFFSET TO APPLICATION NAME STRING (optional)
  325. ; ????              OFFSET TO COMMENTS (optional)
  326. ; ????              UTC TIME/DATE OF IMAGE CREATION
  327. ; ????              UTC TIME/DATE OF IMAGE MODIFICATION
  328. ; ????              VERSION/SUBVERSION OF APPLICATION THAT CREATED IMAGE
  329. ; ????              VERSION/SUBVERSION OF SUPERCARD PRO HARDWARE
  330. ; ????              VERSION/SUBVERSION OF SUPERCARD PRO FIRMWARE
  331. ; ????              VERSION/SUBVERSION OF THIS IMAGE FORMAT
  332. ; ????              ASCII 'FPCS'
  333.  
  334.  
  335. ; ## FILE FORMAT DEFINES ##
  336.  
  337. IFF_ID = 0x00                      ; "SCP" (ASCII CHARS)
  338. IFF_VER = 0x03                     ; version (nibbles major/minor)
  339. IFF_DISKTYPE = 0x04                ; disk type (0=CBM, 1=AMIGA, 2=APPLE II, 3=ATARI ST, 4=ATARI 800, 5=MAC 800, 6=360K/720K, 7=1.44MB)
  340. IFF_NUMREVS = 0x05                 ; number of revolutions (2=default)
  341. IFF_START = 0x06                   ; start track (0-165)
  342. IFF_END = 0x07                     ; end track (0-165)
  343. IFF_FLAGS = 0x08                   ; FLAGS bits (0=INDEX, 1=TPI, 2=RPM, 3=TYPE - see defines below)
  344. IFF_ENCODING = 0x09                ; BIT CELL ENCODING (0=16 BITS, >0=NUMBER OF BITS USED)
  345. IFF_HEADS = 0x0A                   ; 0=both heads are in image, 1=side 0 only, 2=side 1 only
  346. IFF_RSRVED = 0x0B                  ; reserved space
  347. IFF_CHECKSUM = 0x0C                ; 32 bit checksum of data added together starting at 0x0010 through EOF
  348. IFF_THDOFFSET = 0x10               ; first track data header offset
  349. IFF_THDSTART = 0x2B0               ; start of first Track Data Header
  350.  
  351. ; FLAGS BIT DEFINES (BIT NUMBER)
  352.  
  353. FB_INDEX = 0x00                    ; clear = no index reference, set = flux data starts at index
  354. FB_TPI = 0x01                      ; clear = drive is 48TPI, set = drive is 96TPI (only applies to 5.25" drives!)
  355. FB_RPM = 0x02                      ; clear = drive is 300 RPM drive, set = drive is 360 RPM drive
  356. FB_TYPE = 0x03                     ; clear = image is has original flux data, set = image is flux data that has been normalized
  357. FB_MODE = 0x04                     ; clear = image is read-only, set = image is read/write capable
  358. FB_FOOTER = 0x05                   ; clear = image does not contain a footer, set = image contains a footer at the end of it
  359.  
  360. ; MANUFACTURERS                      7654 3210
  361. man_CBM = 0x00                     ; 0000 xxxx
  362. man_Atari = 0x10                   ; 0001 xxxx
  363. man_Apple = 0x20                   ; 0010 xxxx
  364. man_PC = 0x30                      ; 0011 xxxx
  365. man_Tandy = 0x40                   ; 0100 xxxx
  366. man_TI = 0x50                      ; 0101 xxxx
  367. man_Roland = 0x60                  ; 0110 xxxx
  368.  
  369. ; DISK TYPE BIT DEFINITIONS
  370. ;
  371. ; CBM DISK TYPES
  372. disk_C64 = 0x00                    ; xxxx 0000
  373. disk_Amiga = 0x04                  ; xxxx 0100
  374.  
  375. ; ATARI DISK TYPES
  376. disk_AtariFMSS = 0x00              ; xxxx 0000
  377. disk_AtariFMDS = 0x01              ; xxxx 0001
  378. disk_AtariFMEx = 0x02              ; xxxx 0010
  379. disk_AtariSTSS = 0x04              ; xxxx 0100
  380. disk_AtariSTDS = 0x05              ; xxxx 0101
  381.  
  382. ; APPLE DISK TYPES
  383. disk_AppleII = 0x00                ; xxxx 0000
  384. disk_AppleIIPro = 0x01             ; xxxx 0001
  385. disk_Apple400K = 0x04              ; xxxx 0100
  386. disk_Apple800K = 0x05              ; xxxx 0101
  387. disk_Apple144 = 0x06               ; xxxx 0110
  388.  
  389. ; PC DISK TYPES
  390. disk_PC360K = 0x00                 ; xxxx 0000
  391. disk_PC720K = 0x01                 ; xxxx 0001
  392. disk_PC12M = 0x02                  ; xxxx 0010
  393. disk_PC144M = 0x03                 ; xxxx 0011
  394.  
  395. ; TANDY DISK TYPES
  396. disk_TRS80SSSD = 0x00              ; xxxx 0000
  397. disk_TRS80SSDD = 0x01              ; xxxx 0001
  398. disk_TRS80DSSD = 0x02              ; xxxx 0010
  399. disk_TRS80DSDD = 0x03              ; xxxx 0011
  400.  
  401. ; TI DISK TYPES
  402. disk_TI994A = 0x00                 ; xxxx 0000
  403.  
  404. ; ROLAND DISK TYPES
  405. disk_D20 = 0x00                    ; xxxx 0000
  406.  
  407.  
  408. ; ------------------------------------------------------------------
  409. ; TRACK DATA HEADER FORMAT
  410. ; ------------------------------------------------------------------
  411. ;
  412. ; 0000              'TRK' (ASCII CHARS)             - 3 chars
  413. ; 0003              TRACK NUMBER                    - 1 byte
  414. ; ....              START OF TABLE OF ENTRIES FOR EACH REVOLUTION
  415. ; 0004              INDEX TIME (1st REVOLUTION)     - 4 bytes
  416. ; 0008              TRACK LENGTH (1st REVOLUTION)   - 4 bytes
  417. ; 000C              DATA OFFSET (1st REVOLUTION)    - 4 bytes (offset is from start of Track Data Header)
  418. ; ....              ADDITIONAL ENTRIES FOR EACH REVOLUTION (IF AVAILABLE, OTHERWISE THIS WILL BE FLUX DATA)...
  419. ; 0010              INDEX TIME (2nd REVOLUTION)     - 4 bytes
  420. ; 0014              TRACK LENGTH (2nd REVOLUTION)   - 4 bytes
  421. ; 0018              DATA OFFSET (2nd REVOLUTION)    - 4 bytes
  422. ; 001C              INDEX TIME (3rd REVOLUTION)     - 4 bytes
  423. ; 0020              TRACK LENGTH (3rd REVOLUTION)   - 4 bytes
  424. ; 0024              DATA OFFSET (3rd REVOLUTION)    - 4 bytes
  425. ; 0028              INDEX TIME (4th REVOLUTION)     - 4 bytes
  426. ; 002C              TRACK LENGTH (4th REVOLUTION)   - 4 bytes
  427. ; 0030              DATA OFFSET (4th REVOLUTION)    - 4 bytes
  428. ; 0034              INDEX TIME (5th REVOLUTION)     - 4 bytes
  429. ; 0038              TRACK LENGTH (5th REVOLUTION)   - 4 bytes
  430. ; 003C              DATA OFFSET (5th REVOLUTION)    - 4 bytes
  431. ; .... etc. etc.
  432. ;
  433. ;
  434. ; INDEX TIME = 32 BIT VALUE, TIME IN NANOSECONDS/25ns FOR ONE REVOLUTION
  435. ;
  436. ; i.e. 0x7A1200 = 8000000, 8000000*25 = 200000000 = 200.00000ms
  437. ;
  438. ; TRACK DATA = 16 BIT VALUE, TIME IN NANOSECONDS/25ns FOR ONE BIT CELL TIME
  439. ;
  440. ; i.e. 0x00DA = 218, 218*25 = 5450ns = 5.450us
  441. ;
  442. ; Special note when a bit cell time is 0x0000.  This occurs when there is no flux transition
  443. ; for at least 65536*25ns.  This means that the time overflowed.  When this occurs, the next
  444. ; bit cell time will be added to 65536 and that will be the total bit cell time.  If there
  445. ; are more than one 0x0000 entry, then 65536 is added for each entry until a non-0x0000 entry
  446. ; is found.  You will see 0x0000 when encountering 'strongbits' (no flux area) type of
  447. ; protection schemes.
  448. ;
  449. ; i.e. 0x0000, 0x0000, 0x7FFF = 65536 + 65536 + 32767 = 163839*25 = 4095975ns
  450. ;
  451. ; The number of bitcells only increases by the number of entries, and not affected by the
  452. ; overall time.  So, in above example even though the time could be what thousands of bitcells
  453. ; times would normally be, the number of bitcells would only be 3 entries.
  454.  
  455.  
  456. ; ## TRACK DATA HEADER DEFINES ##
  457.  
  458. TDH_ID = 0x00                      ; "TRK" (ASCII CHARS)
  459. TDH_TRACKNUM = 0x03                ; track number
  460. TDH_TABLESTART = 0x04              ; table of entries (3 longwords per revolution stored)
  461. TDH_DURATION = 0x4                 ; duration of track, from index pulse to index pulse (1st revolution)
  462. TDH_LENGTH = 0x08                  ; length of track (1st revolution)
  463. TDH_OFFSET = 0x0C                  ; offset to flux data from start of TDH (1st revolution)
  464.  
  465. ; ------------------------------------------------------------------
  466. ; EXTENSION FOOTER FORMAT
  467. ; ------------------------------------------------------------------
  468. ;
  469. ; 0000           DRIVE MANUFACTURER STRING OFFSET            - 4 bytes
  470. ; 0004           DRIVE MODEL STRING OFFSET                   - 4 bytes
  471. ; 0008           DRIVE SERIAL NUMBER STRING OFFSET           - 4 bytes
  472. ; 000C           CREATOR STRING OFFSET                       - 4 bytes
  473. ; 0010           APPLICATION NAME STRING OFFSET              - 4 bytes
  474. ; 0014           COMMENTS STRING OFFSET                      - 4 bytes
  475. ; 0018           IMAGE CREATION TIMESTAMP                    - 8 bytes
  476. ; 0020           IMAGE MODIFICATION TIMESTAMP                - 8 bytes
  477. ; 0028           APPLICATION VERSION (nibbles major/minor)   - 1 byte
  478. ; 0029           SCP HARDWARE VERSION (nibbles major/minor)  - 1 byte
  479. ; 002A           SCP FIRMWARE VERSION (nibbles major/minor)  - 1 byte
  480. ; 002B           IMAGE FORMAT REVISION (nibbles major/minor) - 1 byte
  481. ; 002C           'FPCS' (ASCII CHARS)                        - 4 bytes
  482.